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OVERVIEW OF RELATIONAL PROGRAMMING* 



B. J. MacLennan 
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November 10, 1981 



1 . Introduction 

Relational programming is a method of programming based on the 
use of a relational calculus. We begin by explaining why we have 
chosen to investigate relational programming. 

We began investigating relations to try to a find a high 
level way of manipulating complex data structures. Languages 
such as A PL are very successful in the manipulation of vectors 
and matrices, and languages such as Snobol are useful in the 
manipulation of strings. Unfortunately, these are both examples 
of linear data structures, and many problems in computer science 
require non - linear data structures, such as trees and networks. 
Proposed extensions to A PL and Snobol to handle non-linear data 
structures have not been very successful. 

It is well known that almost any data structure can be 
described bv a relation. In effect, then, any operation on rela- 
tions can be thought of as an operation on data structur-es. 
■Pher^fore, it seemed that the high level relational operators 

* '’’he work reDorted herein was supported by the Foundation 
Pesearch Program of the Naval Postgraduate School with funds 
provided by the Chief of Naval Research. 
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provided by a relational calculus might provide a source of high 
level operations for manipulating non-linear data structures. 
This has proved to be the case. 

Backus [1] has described the advantages of programming with 
f unctionals , that is, with functions which operate on other func- 
tions. Functionals allow the high level combination of programs 
to yield new programs. Now notice, since every function is a 
relation, every relational operator is in effect a functional. 
Therefore, the same set of operators that are used for manipulat- 
ing data can also be used for manipulating programs. The result 
is great economy of linguistic mechanism in combination with 
powerful means of manipulating both code and data. 

A final goal in the development of relational programming 
has been the attempt to find a- means of programming that permits 
practical proofs of real programs. The fact that relations are 
mathematically tractable, and that there is an well-developed 
theory of relations, has encouraged this study. 

2 . Background 

Relational programming has been based on naive set theory . This 
is the set theory that most people are exposed' to in every 
mathematics class from freshman- calculus on. It is hoped that by 
basing this programming method on a simple and well-known 
mathematical basis, it will be more understandable to people 
without an extensive mathematical background. 



2 



There are three sorts of objects with which relational pro- 
grams deal: 

* Individuals 

* Sets 

* Binary Relations 

The individuals are the indivisible data values with which we 
compute. Typically they will include integers, real numbers, 
characters, and Boolean values. Eoth the sets and the relations 
may be either finite or infinite; the latter being represented on 
a finite computer using intensional methods (discussed later). 
Both the sets and relations are typeless , which means that there 
are no restrictions on what sets or relations can be members of 
other sets and relations. Axiomatizations of set theory often 
included intricate type systems (such as Russell's "Ramified Type 
Theory") to prevent contr ad ictions . However, as is discussed in 
C 3 ! , there are other methods of preventing contradictions that do 
not depend on elaborate type systems. Some of the factors that 
have convinced us that a typeless system is more appropriate to 
programming are discussed in [33- 

We use the notation x € S to mean that x is a member of the 
set S, and xRy to mean that the pair <x,y> is a member of the 
relation R. The functional notation Fx denotes the unique y (if 
it exists) such that xFy. In general spaces and the case of 
letters will be used to improve readability. Parentheses are 
used for grouping in the usual way. 
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3. Relations and Functions 



3 . 1 Functionals 

Since every function is a relation, every operation on relations 
is also an operation on functions, i.e., a functional. In this 
section we will investigate several relational operators and show 
that they have useful functional interpretations. 

The relative product operation on relations performs the 
composition of functions. That is, 

f .g (x) = f ( g ( x ) ) 



We will sometimes also write this in its rightward form: 

f ;g (x) = g(f(x) ) 



The union operation, when applied to functions, combines them. 
This is most useful when the functions have disjoint domains. 
For example, 



f|g (x) 



f(x), ifx 6 dom f 

.g ( x ) , if x 6 dom g 



(We write 'dom f' for the domain of f.) 

If the functions do not have disjoint domains, the ordered 
union , or overlaying operation, f/g, is often useful: 

if x € dom f 



f/g (x) 



f(x) , 
g( x) , 



otherwise 



That is, the pairs in f supercede the corresponding pairs in g. 



The converse of a relation, when applied to a function, pro- 
duces the inverse function. That is, 

x = f “ 1 (y) iff y = f(x) 

Notice that this operation is always defined since a relation 
always has a converse. Of course, the inverse of a function will 
be a function only if the original function was one-to-one. 
Nevertheless, because the converse is always defined it satisfies 
simpler properties. 

The restrictions are useful operations on relations; they 
define subrelations of the given relation whose members satisfy a 
given property. When applied to functions, the restriction 
operations limit the domain, range, or both the domain and range 
of a function. They are defined: 



y = 


5 f ( x) 


iff 


y = f(x) 


and 


x € s 


y = 


f S ( X ) 


iff 


II 

♦“»> 

X 
' 


and 


y € s 



fOS 



s — > f <— s 



where s is any set. As will be shown later, the restriction 
operations are often useful for constructing conditionals. 

The image operation ,' when applied to a function, gives the 
image of a set under that function. This is defined: 



img f (S) 



{ y ! 3x € S: y = f(x) } 
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The parallel application operation applies functions to 
corresponding elements of a sequence: 

f||g(x,y) r ( f x , g y ) 

The dual application or construction operation applies several 
functions to one argument, returning a sequence of the results: 

f # g ( X ) = ( f X , g X ) 

This is equivalent to 3ackus' construction operation, [f,g]. 

The closure operators effectively iterate the application of 
a function. The transitive and non-transitive closures are 
defined : 

* 

i. — 

r + = 

where f n means the composition of f with itself n times. Thus 
the result of f + (x) is whichever of f (x), r (x), ... are 

defined. (If more than one are defined we can use the restric- 
tion operations to pick the one we want.) 

3 . 2 Control Structures 

So far in the development of relational programming there has 
been no need to in toduce control structures in the conventional 
sense. This is because the relational operators are adequate to 
express most control flow situations. For example, suppose we 
wish to apply f(x) if x satisfies s and g(x) otherwise; this is 
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effectively a conditional construction. It can be written this 



way using the relational operators: 

s “> f / g 



This is equivalent to 

(s -> f) 1 (non s -> g) 

('non s' returns the complement of the set s.) In other words, 
the domain of f is restricted to those things that do satisfy s 
and the domain of g is restricted to those things that don’t 
satisfy s. This can be diagramed like this: 




The s and s can ^e thought of as filters on the inputs of f and 
g. Since they are mutually exclusive, it is guaranteed that at 
most one value will be produced for each value put in. 



The relational equivalent of loops are constructed from the 
closure and restriction operators. Consider this function: 

(s->f) + <- non s 



The application of s*)f will be iterated one or more times, 
which means that f will be applied one or more times, as long as 
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its input satisfies s. An output from this process is allowed 
only if it doesn't satisfy s. We can diagram this function: 






s 



S’ 





This is the equivalent of a "repeat until'' loop in Pascal. Simi- 
lar expressions loop zero or more times, like a Pascal "while" 
loop . 

3 . 3 Relations Obey Simple Laws 

One of the reasons we have investigated relational programming is 
that it simplifies reasoning about programs. This is because 
relations obey many simple laws. For example, 

(f.g)’ 1 = g^.f" 1 

is true for all relations; it is only true for functions that are 
one-to-one . 

3 . U Multiple-Valued Functions 

A relation can be thought of as a multiple - valued function. That 
is, there may be several y such that xFy. Functional approaches 
to programming often exclude multiple-valued functions and non- 
deterministic functions, even though these are often benign . 
Relational programming deals naturally with multiple valued func- 



tions. 



For example, suppose that g(x) is multiple-valued, e.g., 



there are three values, a, b, and c, such that xga, xgb, and xgc. 
Further suppose that the function f has the same value, y, on 
each of a, b, c. That is, y = f(a), y = f(b), and y = f(c). 
Then it is perfectly meaningful to write 

y = f .g ( x) 

even though g is not single-valued at x. This can be visualized: 




4 . Relations and Data 
4 . 1 Finite Functions 

We will now turn to the representation of data by relations and 
the high-level data manipulation functions provided by the rela- 
tional operators. Although there are several ways that data can 
be represented by relations, one of the simplest is by finite 
functions , i.e., functions containing a finite number of pairs. 
This repr esentation is particularly suitable for arrays and 
records. For example, 



x = A(i) 

is the application of an array A to its index i. Similarly, 

x = z ( r e ) 

is analogous to a field selection operation z.re, but in rela- 
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tional terms it is also just the application of a function to an 
argument . 

The value of viewing data in this way is that it makes data 
structures amenable to the relational operators. For example, 
the converse operator inverts a structure. 

i = A ~ \ X ) 

returns the index of the array element whose value is x . If x 
occurs several times in A then A””' is multiple-valued. We can 
get a set of all the indices where x occurs by taking the image: 
img A " 1 ( x ) . 

The relative product or composition operation can be used 
for many purposes, such as permuting arrays. If P is a permuta- 
tion function (a bijection from the index set into itself), then 
A. D is the corresponding permutation of A. This operation can 
also be used for "cascading" data structures. For example, if 

'address' is a table such that 

a = address(n) 

means that a is the address of the variable' named n, and 'value' 
is a table such that 



v = value(a) 

means that v is the value contained by location a, then 
' value . address ’ is a cascaded table such that 
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V 



value . address (n) 



means that v is the value of the variable named n. 

The restriction operation can be used to define substruc- 
tures. For example, suppose that M is a finite function 
representing a two-dimensional matrix: 





X - 


M 


( i , J ) 










That is, M is 


a function that 


takes pairs 


of 


integers 


into 


the 


corr espond ing 


matrix elements. 


If I and J 


are index 


sets 


, the 


submatrix of M 


corr espond ing 


to 


these 


index values 


is 


just 



(IXJ'i -»M, since this restricts the first and second indices of 
^ to be in I and J respectively. 

The union operation can be used to combine data structures, 
^or example, if S and T are tables, then S]T is a table that con- 
tains the entries of both S and T. Also, if U and V are two 
arrays with consecutive index sets (which is not hard to 
arrange' 1 , then U|V is the catenation of U and V. 

The overlaying operation U/V updates an array V according to 
the pairs in U. That is, if U/V(i) = U(i) if U(i) is defined, 
and U/VCi) = ,r (i) otherwise. 

r ina!ly, the image operation can be used for mass selec- 
tions. For examDle, if A is an array and S is a set of indices, 
then img A (S'! is the set of all elements of A selected by 



indices in S. 



4 . 2 Sequences 



Sequences and lists have a straight-forward representation as 
relations. If we draw the sequence of elements (a,b,c,d) like 
thi s : 



S = a ^ 

then you can see that this can be represented by the relation xSy 
that relates x to y just when there is an arrow from x to y. 
That is, 



S = { <a,b>, <b ,c> , <c,d> } 

Next we consider the effect of the relational operators on such a 
sequence. 

The converse of S is that relation S~\ where yS _1 x if and 
only if xSy. The effect is to reverse the arrows: 




so it can be seen that S -1 is just the reverse of S. 

Like all relations, a sequence can be thought of as a func- 
tion. The effect of functional application is to follow an arrow 
from one element of the sequence to another, e.g., 

c = S ( b ) and b = S ” 1 ( c ) 

p 

Of course, S goes two links: 
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d 



and 



b 



S " 2 (d) 



= S 2 ( b ) 



and so forth. 

The restriction operation can be used to define subsequences 
of a given sequence. For example, SOP defines the subsequence 
of S all of whose elements satisfy the predicate P. That is, if 
P is the set of positive numbers, then this restriction has just 
the positive members of S. 

The union operation can be used in various ways to combine 
sequences. For example, to catenate the sequences S and T we can 
write 



S ! (last S, first T) ! T 

This combines S and T with a third relation which is a sequence 
from the last element of S to the first element of T. 

Finally, we can use the domain functions to find dis- 
tinguished elements of a sequence. For example, the initial 

members of a sequence (of which there is exactly one) are those 
members that have an arrow leaving them, but not pointing at 
them. In other words the initial members are the elements of the 
domain that are not in the range: 

init(S) = dom(S) _ dom(S“^) 

4 . 3 General Data Structures 

Since the manipulation of non-linear data structures was a major 
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reason for investigating relations, we would expect to find that 
the relational operators are useful. The sam.e approach is used 
as for sequences. For example, the graph 

T = 

d 

is represented by the relation 

T = {<a,b>, <a,c>, <b,d>, <b,e>, <c,e>, <c,f>, <c,c>} 

Then, it is easy to see that the roots of this structure are just 
its initial members, init(T), and the leaves are the initial 
members of the converse relation, init(T _1 ). The latter are 
usually called terminal members. 

Notice that T(n) follows an arrow from node n, which may be 
multiple-valued. For example, T(b) could be d or e. Therefore, 
it is better to ask for all the descendents of a node n, which is 
just the image of T applied to n: 

descendents(T) = img T (n) 

5 • Higher Levels of Abstraction 

The relational programming style is open ended and easily admits 
even higher levels of abstraction. Observe that the relational 
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operators are themselves functions (in particular, functionals). 
Therefore, these functions can be manipulated and combined by the 
relational operators. Therefore, higher level operators can be 
built without the use of a "formal'’ (i.e., data based) represen- 
tation, such as that used in LISP or Backus's FFP system [1]. 
This is a natural outgrowth of the fact that relational program- 
ming deals with a single kind of entities, relations, and uses 
them for all purposes. Second and higher level functionals have 
not been seriously investigated yet, although they seem to arise 
naturally from the attempt to eliminate variables. 

6 . Status 

In this section we summarize the current status of our investiga- 
tion into relational programming. 

The operators are undergoing a continuing refinement. We 
began with the operators defined by Russell and Whitehead [7] and 
Carnap [2]. As the requirements of using a relational calculus 
for programming have emerged, we have modified the meaning of 
several of their operators, dropped some, and added others. 

The notation is undergoing a continuing evolution, as is 
apparent in any comparison with our earlier reports [4, 5]. The 
notation used in this paper is more in conformity with mathemati- 
cal custom and is easier to read and type. We anticipate that 
this evolution will continue; it would be premature to freeze it 
at this time . 
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In an attempt to better access the value of relational pro- 
gramming, we have begun the implementation of several trial 
applications. One of these is a table-driven syntax-directed- 
editor and generator of the type described in [6]. The resulting 
relational program is about a page long. It will be described in 
a future technical report. 

We have consciously avoided allowing implementation con- 
siderations to influence the early development of relational pro- 
gramming. This is because we did not want to prejudice the study 
by particular assumptions about machine architecture. Rather, we 
have hoped that the investigation of relational programming will 
guide us to the machines we should be building. Recently, how- 
ever, we have begun the investigation of some possible represen- 
tations of relations along with an analysis of the complexity of 
the corresponding algorithms. This will be reported in a forth- 
coming thesis from the Naval Postgraduate School. 

We have been attempting the practical proof of some rela- 
tional programs. This simple properties which relations satisfy 
makes this a feasible undertaking. 

Finally, we have begun the implementation of simple exten- 
sional and intensional representations and implementations of the 
relational operators. The goal here is to provide a system to 
allow ’’hands-on’’ experience with relational programming. This is 
a necessary part of the evaluation of any new programming style. 
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Old Notation Name 



New Notation 



x € c 


class membership 


x € C 


xC 


f* 


ft 


xRy 


relation membership 


x Ry 


F : x 


function application 


F x 


R " 1 


converse 


R " 1 


’ : R 


tf 


in v R 


lem : R 


domain 


dom R 









Lm : R 


ft 


ft 


rim : R 


codomain 


dom.inv R 


V 






Rm : R 


ft 


ft 


mem : R 


members 


mem R 


R! 


image 


img R 


i : x 


unit class 


un x 


0: C 


unit class selector 


the C 






unimg R 


R 


unit image 






unimg.inv R 


R 


unit coimage 


R}S 


right restriction 


R <e- S 


S<R 


left restriction 


S -> R 


RSS 


restriction 


ROS 


R A S 


intersection 


R&S 


R V S 


union 


R IS 


R-S 


di f ference 


R-S 


-R 


complement 


non R 


x+y 


addition 


x+y 


x-y 


subtraction 


x-y 
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x*y 


multiplication 


x*y 


x/y 


division 


x%y 


I 


empty class 


<6 


I 


full class 


all, non 6 


C*D 


Cartesian product 


CX D 


R j S 


relative product 


R ; S 


RS 


functional composition 


R.S, R'S 


= , I 


identity 


= , Id 


init : R 


initial members 


init R 


term : R 


terminal members 


init.inv R 


oc : R 


first member 


first R 


iu: R 


last member 


first.inv R 


Q.: R 


final members 


final R 


A: R 


initial members 


inv .final .inv 


min : C 


minimum 


min C 


max : C 


maximum 


max C 


x ,y 


pair 


x : y 


0 


ff 


!» 


# : C 


size 


size C 


Curry : C 


Cur r y 


graph - ^ C 


Curry ~ ^ : R 


graph 


graph R 


r. 

3 


parallel application 


r | | s - 


d 


construction 


r#s 


(it) 


binary operator 


(it) 


(xn) 


left binding 


( x Tr ) 


( iry) 


right binding 


( Tty) 


* 




* 


R 


reflexive trans . closure 


R , retrac R 



20 



R + 


transitive closure 


R + , trac R 


R n 


relation power 


. R n 


f : :g 


meta-application 


f : :g 


f Rf ’ 1 


isomorphic image 


f$R 


Md : ( g , f ) 


overlaying 


f/g 


R S S 


subset 


RSS 


R -> S 


ff 


RCS 


e 


empty relation 


6 X 6 


9 


full relation 


all X all 


m . . n 


closed interval 


(unimg >) m 


CX D 


cross product 


graph( C X D) 




explicit relation 


( a : b | ... 


s't 


catenate 


s~t 


<a , b , . . . , z> 


sequence 


(a ,b , . . . , z) 


f§ i 


reduction 


fgi 



& ( un img O n 
y :z) 



Mote! The major difference between the new and old notations is 
that y=Fx now means xFy, whereas previously it meant yFx. This 
means that separate operators are now needed for relative pro- 
duct and composition. These are related by R.S = S;R. This 
effects the interpretation of several other relations and 
classes. For example, functions are now the r ight-un ivalent 
(run) relations, whereas previously they were the left-univalent 
(lun) relations. Also, the domain of a function is its left 
members, rather than its right members. 
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